home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Power Tools 1993 November - Disc 2
/
Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso
/
hotlines
/
swthl
/
uxrxwh
/
rxuxwhit.txt
< prev
next >
Wrap
Text File
|
1993-04-13
|
42KB
|
815 lines
Metrics discussion: Providing a robust set of performance metrics
The first challenge faced was providing a robust set of fully validated
performance metrics which would serve as a base for tool development.
Realizing that current kernel instrumentation (/dev/kmem) was both
insufficient and in several areas incorrect, we decided to undertake a
major effort to develop a new mechanism for kernel instrumentation. The
result of our efforts is the Measurement Interface (MI). The MI is a joint
development effort between the Performance Technology Center, Workstation
Systems Group, and the HP-UX kernel labs for both the Series 300 and Series
800 platforms. The MI offers the following benefits:
- a robust set of validated kernel counters and event traces;
- a low overhead interface to kernel instrumentation; and
- a uniform user level interface to kernel instrumentation which is
independent of specific HP-UX release or other kernel specific
features.
The MI is internally supported in HP-UX release 7.0 and later. Figure 1
shows how the HP-UX Measurement Interface is implemented.
<Figure 1>
Sources of performance data
The MI is based on three sources of data which provide a robust set of
validated performance counters and event traces.
- Kernel Instrumentation:
The Kernel Instrumentation (KI) package supplies system activity
metrics in the form of event driven trace buffers. Within the HP-UX
kernel, stub routines have been inserted in specific kernel functions
to capture process and kernel event transitions. Each transition
generates a corresponding trace record which serves to track key data
related to the event. The individual trace records are stored in one
of four 8 kbyte trace buffers within kernel memory. It is important
to note that the KI is currently evolving, and its implementation is
subject to change.
Whenever a kernel trace buffer becomes full, a user daemon (midaemon)
process wakes up and reads the data from the KI produced trace buffer,
converts the trace records into meaningful counters, and stores that
data into shared memory. The midaemon is used to process kernel trace
buffers into shared memory for the following reasons:
1) kernel memory is a scarce resource and it is not feasible
to maintain numerous trace buffers within this area. The
midaemon program has been tuned to ensure trace buffers are
processed from kernel memory into shared memory in a timely
fashion such that trace data is not lost;
2) the kernel trace buffers must be converted into
meaningful counters representing time and frequency
information about the occurrence of events. This conversion
of trace buffer data into counter data significantly reduces
the volume of performance data maintained within shared
memory; and
3) shared memory can be utilized as a fast interprocess
communication area, allowing performance tool collection
routines the ability to sample and log the performance
counter information easily and efficiently.
Under the current implementation, the midaemon process converts and
groups trace records into six counter classes. The class definitions
are as follows:
Configuration NFS
Global Cluster
IO Process
Each counter class is further subdivided into subclasses which serve
to track specific event activity related to the class. For example,
the Global class is divided into subclasses for global disk activity
counters, global response time counters, global memory counters, etc..
Approximately 90% of the performance counter information provided by
the measurement interface is sourced from the KI interface package.
- Validated kernel counters:
The second source of data is groups of in-line kernel counters which
have been validated and are accessible via a KI implemented KMEM
(/dev/kmem) extract call. For example, Global class memory counters
are obtained directly from the vmmeter structure via the KMEM call.
- Direct hardware calls:
In addition to the performance metrics provided via the measurement
interface, several IO related performance metrics are captured
directly from device interface cards. The 'ioctl' system call is
utilized to read performance information directly from the device
interface card. For example, this technique is used to capture LAN
related metrics (packet rates, errors, and collisions).
Overhead
An overriding design goal of the measurement interface was to minimize
its memory and CPU overhead on the system. After all, it is not
appropriate for the tool and underlying instrumentation being utilized
to measure your systems performance to itself have a negative
performance impact. The measurement interface utilizes between 0.5% -
3% CPU on average and requires 300K of shared memory on an average
system. To support the data collection methodologies required by
differing performance needs, an MI interface library was implemented
to provide a uniform user level interface to counter information
maintained in shared memory by the midaemon. This approach also
provided an interface which is independent of a specific HP-UX release
or other kernel specific features. Currently, the library calls are
undocumented and not available for distribution from Hewlett Packard.
Collection discussion: Providing a continuous, low overhead data
collection mechanism
Supplementing the measurement interface is a specialized data collection
program, scopeux. Performance tool collection routines are required for
two reasons: (1) the midaemon program does not have the bandwidth to log
performance counter information to disk without the potential of losing
valuable trace buffer data, and (2) the midaemon program offloads the
overhead associated with processing KI traces from individual performance
tools.
Overview
For a given performance need, the appropriate data collection mechanism can
vary greatly. For example, a real-time diagnostic tool may require
performance data about individual processes every few seconds; a capacity
planning tool may require data collection specific to programs running on
the system over periods of several months. HP LaserRX/UX is built to serve
the needs of the system manager in terms of the ability to diagnose system
problems, tune a system for optimal performance, balance system workloads,
manage user service levels, and plan for future resource needs. In an
ideal world, the goal of a system manager is to have the ability to solve
system performance issues in a proactive manner such that they never
surface as user problems. In the real world, most system managers are so
busy reacting to user problems that they never have a chance to solve
performance issues in a proactive manner. HP LaserRX/UX was designed to
provide the reactive system manager with a tool he can use to solve today's
performance issues as well as gain some insight into what issues may
surface next week, next month, or even next year.
Scopeux was designed with the following goals in mind:
- continuous, long-term data collection mechanism to support the
resolution of current and future system management issues;
- configurable collection environment controlled by the system manager.
- tiered collection scheme to facilitate a structured approach to system
performance analysis.; and
- low CPU and disk overhead requirements.
Figure 2 shows how the Scopeux data collection environment is
implemented.
<Figure 2>
The scopeux data collection program is officially supported on HP 9000
Series 800/300 system running HP-UX 7.0 and later. Scopeux is designed to
continually run on your HP 9000 system, collecting performance data
supplied from the measurement interface and IO devices, sampling and
summarizing the data, and logging it to disk. Performance data is
collected and logged at three levels; Global, Application (user-defined
collection of related processes), and Process.
Continuous Collection
Continuous data collection provides the system manager with the ability to
view and analyze system performance over time, allowing the system manager
to proactively monitor and manage computing resources. Viewing system
performance data over time becomes especially valuable after you have
collected several months worth of performance data and have the ability to
visualize trends which may exist on your HP 9000 system. Continuous data
collection also provides the system manager with the ability to react to
the day to day performance issues in a more efficient manner. Since a
historical log of system activity exists, most user problems can be
validated and fixed without the difficult and time consuming task of having
to duplicate the problem.
To achieve the design goal of continuous data collection, several decisions
had to be made with respect to the amount and resolution of the performance
data being collected. The following guidelines were determined:
- only key performance indicators would be collected and logged to disk,
and
- on a system with average activity, no more than 1 Mbyte of data should
be collected per day, and CPU overhead of the collection process
should average less than 5%.
Data Resolution
Performance data is averaged over the time interval. For global and
application data, five one-minute samples are used to determine the five-
minute average. For process data, one sample is used. For process data,
it is important to note that data is not lost for processes that begin and
terminate within the sampling interval. By default process data is
collected whenever a process is created or terminated.
Experimentation helped set the resolution of the data collection at five
minutes for global and application data, and every one minute for process
data. The scopeux collection program is responsible for summarizing
collected data on the five minute interval for global and application data
and on the one minute interval for process data.
Where necessary, low level performance metrics were combined into more
generalized key performance indicators. For example, the measurement interface
provides more than twenty process stop reasons; scopeux combines these metrics
into ten meaningful stop reason indicators.
Parameter file
To provide the system manager with the flexibility to customize the data
collection environment, the scopeux collection program reads a parameter
file (PARM) each time it is started. The PARM file contains information
which instructs the scopeux program about its collection environment. For
example, the system manager may specify PARM file options which control the
type of data which gets collected and logged, the size of disk logfiles,
thresholds for data collection, user-defined application definitions, etc..
If a PARM file does not exist the scopeux collection program uses pre-
defined defaults.
Data hierarchy
As mentioned above, performance data is collected using a tiered scheme
which permits an hierarchical approach to performance analysis. Data is
collected on three levels; High-Level Global data, Medium-Level Application
data, and Low-Level Process data.
- Global:
System wide performance information. These metrics show overall
system resource utilization and/or information. For example, the
overall CPU utilization metric represents CPU resource consumption on
behalf of all processes running on the system.
- Application:
Process-level performance information grouped by HP LaserRX/UX user-
defined applications (classes). The system manager has the ability to
group individual processes which run on your system into user-defined
applications. Processes not grouped into a user-defined application
are automatically grouped into an application called 'OTHER'. This
ensures that all processes which run on the system are bucketed into
an application. These metrics show overall system utilization /
information on behalf of a single application. For example, if you
wanted to define an application that measured the collective impact of
the `Month End Accounting' environment on your system you would do the
following:
Define an application called 'Accounting' (PARM file).
application = Accounting
Specify which processes running on your system should be grouped
into this application (PARM file).
file = acct*, stock, finance, payroll, report, print
Whenever one of the programs listed in the file parameter is run on
your system , its resource consumption will be attributed to the
application `Accounting'. Note that wildcard characters can be used
to simplify process identification. Processes are bucketed into
applications based on name, not path. Therefore, two processes with
the same name, but different paths will be bucketed as the same
process within an application. Other techniques for applications are
provided as well (e.g. USER LOGON.)
- Process:
Process level performance information. These metrics show resource
utilization / information on behalf of a single process. Since
process level data is the most frequent type of data encountered, HP
LaserRX/UX provides the system manager with the ability to set user-
defined thresholds (CPU consumption, disk IOs, transaction rates,
etc.) that a process must exceed before it is considered interesting.
This serves two purposes; limits the amount of non-interesting data
that might otherwise be collected, and allows the system manager to
focus in on processes that are consuming significant system resources.
For example, if the CPU threshold was set to 10 ( in the PARM file), a
process would have to consume at least 10% of the CPU resource during
a 1 minute interval before it was considered interesting and
performance data was collected on its behalf. If a process does not
exceed one of the user-defined thresholds it is considered non-
interesting and no performance data is collected for that process for
that time interval. By default, all processes are considered
interesting when they are first created (new) and when they terminate
(killed).
The tiered approach to data collection is key to the usability of the HP
LaserRX/UX product as an efficient problem solving tool. Because the data
is organized using this tiered approach (Global - Application - Process),
the system manager is able to use a top-down or hierarchical approach to
problem analysis. The system manager determines the time domain of concern
by viewing Global data, focuses in on which Application during the time
domain is the potential cause of the problem, and then isolates the
Process(es) within the application which is causing the problem.
Data Management
Data is logged to disk using an approach which corresponds to the tiered
data collection scheme. Performance data is logged to three separate disk
logfiles; logglob, logappl, and logproc. These three logfiles are known as
`RAW' logfiles, and correspond to the levels of performance data collected
on your computer system; global, application, and process. Raw logfiles
are updated on a continuous basis. They contain a log of system activity
since the scopeux collector was first started, including the most recent
five minute data sample for global and application data, and the most
recent one minute data sample for process data. Management of the
performance data you have collected is a key component of the HP LaserRX/UX
product. There are two main areas of concern with respect to data
management:
- Disc Space Requirements
You have total control over the amount of disk space consumed by the
HP LaserRX/UX raw logfiles (logglob, logappl, and logproc). When you
start up the scopeux collection process, the following defaults are
used to determine how much disk space each logfile will be allowed to
consume:
Global = 10 Megabytes
Application = 10 Megabytes
Process = 20 Megabytes
Once a given logfile has reached its bound, the oldest 25% of the data
will be automatically rolled out so that new data can be logged. This
circular logfile design ensures that you will not lose any current
performance data.
The system manager can alter the default logfiles sizes with the
`size' parameter in the PARM file. Because each HP 9000 system will
log a different amount of data based on scopeux collector
configuration (PARM file setting) and system activity levels, we
recommend optimizing the size of each of your logfiles based on
personal experience. On average, global data will account for 15% of
raw logfile disk space requirements, application data will account for
25%, and process data will account for 60% of raw logfile disk space.
- Data Management Programs
Two data management programs are shipped with the HP LaserRX/UX
software: extract and utility. Lets look at the data management
features of each program.
Extract: The extract program is used to create a single
logfile containing data from all of or a combination of raw
logfiles. The output file generated from the extract
program is known as an `EXTRACTED' logfile. The key benefit
of an extracted logfile is that it can contain specific
ranges of dates and times of raw logfile data. Data can be
extracted using native 5 minute collection intervals, one
hour summary intervals, or both. For example, if you have
been collecting data for six months, your raw logfiles
contain all the data collected over that time period
(assuming they were large enough). By running the extract
program against the raw logfiles, you can create an
extracted logfile that contains a specific
month/week/day/hour(s) worth of data with only one hour
summaries.
The extract program can be very useful to set up an archive
scheme for your HP LaserRX/UX performance data. For
example, you may only have enough disk space to collect a
months worth of data in your raw logfiles before they reach
their disk space size limit and roll out the oldest 25% of
the data. You can use the extract program to create a
monthly extracted file just before you know your raw .PA
logfiles are going to roll. This extracted file can then be
archived during your system backup procedure. The extract
program can also be used to append raw or extracted data to
an existing extracted logfile. Using the extract program in
this fashion will ensure you have an ongoing log of your
systems performance.
Extracted files can also be downloaded to your PC for local
analysis. You can use extract to subset raw performance
data into logfiles that are reasonable in size for
downloading to your PC hard disc.
Utility: You can use the utility program to find out
specific information regarding the data you have collected.
For example, utility reports on data collection parameters,
disk space requirements, periods when data collection has
been turned off, etc. Utility can also be used to resize
your raw logfiles to avoid a log file roll.
As a general rule of thumb, on a system with average
activity levels, overhead goals have been achieved for both
CPU and disk space requirements. On average, less than 1
megabyte of performance data is collected per day and CPU
overhead for the collection environment (measurement
interface and scopeux) is less than five percent.
Analysis strategy: Providing a centralized top-down approach to Performance
Management
The final challenge of developing any performance tool is inevitability
tied to the presentation of data. The user interface strategy for HP
LaserRX/UX is based on the following realizations:
- the tiered approach to data collection is fundamental for effective
data analysis and must be mirrored within the user interface;
- to interactively view/analyze performance data over time, the user
interface must provide graphical representation of the data;
- graphical work requires significant CPU resources; therefore, the user
interface should not be located on the host machine;
- it is typical for a single system manager to have responsibilities for
systems in a large geographic area; therefore, the user interface
should provide centralized analysis capabilities.
Figure 3 depicts the user interface design for the HP LaserRX/UX product.
<Figure 3>
Overview
The performance workstation serves as a centralized viewing/analysis
station with the ability to access performance data remotely and locally
from the host collection machine(s). This meets two of our stated
purposes: it relieves the host collection machine of the overhead
associated with interactive graphical representation of the performance
data, and provides the system manager with the ability to manage multiple
systems from a central location.
The performance workstation platform is an HP Vectra / IBM AT personal
computer running Microsoft Windows. This performance workstation platform,
running the Performance Analysis Program for HP-UX Systems (laserrx) serves
as the window into the performance data that scopeux has collected on the
HP 9000 Series 300 or Series 800 host computer system. The methodology for
viewing/analyzing data using the laserrx analysis program stems from the
design of the scopeux collection program. Through the power and
functionality of Microsoft windows, Global, Application, and Process data
can be viewed and analyzed interactively in graphical and/or tabular
formats with great ease.
The goal of this hierarchical approach to data analysis is to minimize the
amount of performance data needed to analyze to determine the 'state of
health' of a system. We recommend a top-down methodology to data analysis.
Start by viewing high-level Global data (graphical format), isolating
areas/times of concern. Proceed to medium-level Application data
(graphical format), isolating areas/times of concern for specific
applications. Proceed to low-level Application or Process data (tabular
format) to isolate cause of concern. This approach to data analysis will
save you time by allowing you to quickly pinpoint processes which may be
causing performance bottlenecks on your computer system.
User Interface Highlights:
Window dialog boxes for global and application graphs which allow you to
select the following:
- Graph(s) to display
- Shift (00:00 - 24:00)
- X-Axis Time Domain (Day,Week,Month,Year)
- Ingnore Weekends Flag
- Points Every (5 Minute, Hour, Day)
- Starting Day
Zoom Time and Detail Features:
Once the graph(s) for the given time domain you have selected are
drawn, you can zoom on any time period within the graph based on Time
or Detail. A Time zoom will create a new window that shows a new graph
for the zoomed time period. A detail zoom will create a new window
that shows tabular data for the zoomed period. A zoom detail on a
global graph shows application tabular data and a zoom detail on an
application graph shows process tabular data.
Print and Export Features:
You can print or export any graph or tabular data window. Data can be
exported to an ASCII (.dat) or spreadsheet (.wks) file for
manipulation outside of the HP LaserRX/UX product. This feature is
extremely useful for generating customized reports, etc.
Cut and Paste Feature:
You can copy and undo any graph or tabular data window to the
MicroSoft Windows clipboard. Other applications capable of reading
the MicroSoft Windows clipboard can then import the HP LaserRX/UX
window data.
Configuration Dialog Boxes
Provides a mechanism to save configuration options information (graph
options, serial and LAN connection/disconnection information, etc.) in
permanent storage.
Native Language Support
Provides a mechanism to change date, time, number, and currency
formats to conform to the standards of different countries.
Context Sensitive Help Subsystem
A complete contest sensitive help subsystem provides on-line
documentation about product functionality, graph and tabular metrics.
Metrics Available
Table 1 provides a summary of the performance metrics available for HP
LaserRX/UX at the Global Graph, Application Graph/Tabular, and Process
Tabular levels.
TABLE 1
-------------------------------------------------------------------------
| GLOBAL LEVEL |
-------------------------------------------------------------------------
| Graph | Description |
-------------------------------------------------------------------------
| Bottlenecks | Percent of CPU utilized, Peak Disk Utilization, |
| | and Memory Management overhead. |
-------------------------------------------------------------------------
| Queue Depth | Number of processes queued on CPU, Memory, and |
| | Disk resources. |
-------------------------------------------------------------------------
| Transaction | For a given time interval, number of terminal |
| Response | Transactions logged, average user Think time, |
| | time to First Response, and time to Prompt. |
-------------------------------------------------------------------------
| User CPU | Percent of CPU by: user processes running at |
| | Normal, Nice, and Real-time priorities. |
| | Percent of CPU by process running in kernel mode. |
-------------------------------------------------------------------------
| System CPU | Percent of CPU by: System processes, Context |
| | Switching and Interrupt Processing. |
| | Percent of CPU by processes running in user mode. |
-------------------------------------------------------------------------
| Disk Summary | Read/Write rates (per second) for all disk IO |
| | activity, including total Logical IOs, total |
| | Physical IOs, total Memory Manager IOs. Peak |
| | Disk Utilization. |
-------------------------------------------------------------------------
| Disk Detail | Percent utilization for the five busiest disks |
| | (up to 32 individual disk may be shown). |
| | Read/Write rates (per second) for each individual |
| | disk, including total Logical IOs, total |
| | Physical IOs, total System IOs, total Memory |
| | Management IOs. Disk Utilization. |
-------------------------------------------------------------------------
| LAN Detail | Number of internet packets sent and received, |
| | collisions, and errors for up to 4 individual |
| | LAN cards. |
-------------------------------------------------------------------------
-------------------------------------------------------------------------
| APPLICATION LEVEL |
-------------------------------------------------------------------------
| Graph | Description |
-------------------------------------------------------------------------
| Bottlenecks | Five busiest applications in terms of CPU |
| | Utilization. For up to 15 user-defined |
| | applications: CPU Utilization, Physical Disk |
| | IO Rate, and Memory Utilization. |
| | * One pre-defined application called `OTHER'. |
-------------------------------------------------------------------------
| Transaction | Five busiest applications in terms of Transaction |
| Response | Rate. For up to 15 user-defined applications: |
| | terminal Transactions logged, average user Think |
| | time, time to First Response, and time to Prompt. |
| | * One pre-defined application called `OTHER'. |
-------------------------------------------------------------------------
| User | Five busiest applications in terms of user- |
| Transaction | defined Transaction Rate. For up to 15 |
| Response | user-defined applications: number of user-defined |
| | Transactions logged, average user-defined Think |
| | time, and user-defined time to Prompt. |
| | * One pre-defined application called `OTHER'. |
| | User-defined transaction represent a key |
| | contribution of the HP LaserRX/UX product. |
| | The user can instrument his programs with |
| | 'start_tran' and 'end_tran' calls to define |
| | how a transaction is defined in his terms. |
-------------------------------------------------------------------------
| CPU | Five busiest applications in terms of CPU |
| Utilization | Utilization. For up to 15 user-defined |
| | applications: CPU Utilization, Percent of CPU |
| | by processes running on behalf of application in |
| | user mode at Normal, Nice, and Real-time |
| | priorities, Percent of CPU by processes running |
| | on behalf of application in kernel mode. |
| | * One pre-defined application called `OTHER'. |
-------------------------------------------------------------------------
-------------------------------------------------------------------------
| APPLICATION LEVEL |
-------------------------------------------------------------------------
| Tabular | Description |
-------------------------------------------------------------------------
| Application | Application name, date, and time. |
| Identification | Average number of application that were defined, |
| | active, or terminated during the time interval. |
| | |
| CPU | Percent of CPU utilized by the application. |
| Information | Percent of time an application process spent |
| | executing in kernel mode or user mode (at |
| | normal, nice, and real-time priorities). |
| | |
| Disk IO | Average number of physical and logical disk IOs |
| Information | per second for the application. |
| | |
| Memory | Percent of memory utilized by the application. |
| Information | Sum of virtual data, text, and stack spaces for |
| | all processes active for the application. |
| | |
| Transaction | Number of terminal transactions logged during the |
| Information | time interval. Average think time, time to first |
| | response, and time to prompt for transactions. |
| | Number of user-defined transactions logged |
| | during the time interval. Average think time |
| | and time to prompt for user-defined transactions. |
-------------------------------------------------------------------------
-------------------------------------------------------------------------
| PROCESS LEVEL |
-------------------------------------------------------------------------
| Tabular | Description |
-------------------------------------------------------------------------
| Process | Process name, date, and time. |
| Identification | Process identification number (pid), parent |
| | process identification number (ppid), and process |
| | group leader identification number (pgid). |
| | Process priority and run time. |
| | Reason the process was logged. |
| | User logon name and logon tty (terminal device). |
| | |
| CPU | Percent of CPU utilized over the time interval |
| Information | and over the life of the process. |
| | Percent of time the process spent executing in |
| | kernel mode (system activity, context switching, |
| | and interrupt processing). |
| | Percent of time the process spent executing in |
| | user mode (at normal, nice, and real-time |
| | dispatch priorities). |
-------------------------------------------------------------------------
| Disk IO | Overall disk IO rate during the life of the |
| Information | process. |
| | Average number of logical, physical, system, and |
| | memory management disk IOs per second for the |
| | process during the time interval. |
| | Logical, physical (system and raw IO) read/write |
| | rates for the process during the time interval. |
| | |
| Memory | Resident set size for the process. |
| Information | Sum of virtual text, data, and stack spaces for |
| | the process. |
| | Memory and Disk page fault rate for the process |
| | during the time interval. |
| | |
| Transaction | Number of terminal transactions logged during |
| Information | the time interval and over the life of the |
| | process. Average think time, time to first |
| | response, and time to prompt for transactions |
| | during the time interval and over the life of |
| | process. |
| | Number of user-defined transactions logged during |
| | the time interval and over the life of the |
| | process. Average think time and time to prompt |
| | for user-defined transactions during the time |
| | interval and over the life of process. |
| | |
| Process State | Current state and stop reason for the process |
| Information | (stop reasons include: program, memory, disk, |
| | terminal, other IO, system, diskless (DUX), |
| | network file system (NFS), and interprocess |
| | communication (IPC). |
-------------------------------------------------------------------------
Data Communication
Flexible data communication software is an integral component of the
HP LaserRX/UX product. Both the host collection software and
performance analysis software have bundled data communication services
that provide point to point connection and remote data access between
the performance workstation and HP 9000 host.
The data communications components of HP LaserRX/UX are depicted in
Figure 4.
<Figure 4>
As shown in figure 4, the system manager has two methods for accessing
scopeux performance data via the performance workstation.
Remote File Access:
Remote File Access implies the following: the system manager has made
a remote Serial or LAN connection via the HP LaserRX/UX data
communications software (bundled as part of the HP LaserRX/UX
product). The system manager has remotely opened the logglob `RAW'
logfile or an `EXTRACTED' logfile for analysis.
Once the logfile is opened, viewing and analyzing the performance data
using local verses remote file access is totally transparent. When
possible, we recommend remote file access over a LAN connection as the
method of choice for the following reasons:
Speed:
When a remote data request is made, only the data required to satisfy
the request is returned from the host to the performance workstation.
Since a Series 800/300 CPU is being used to satisfy the data request
and data transfer over the LAN is relatively fast, the graph/tabular
object is typically processed faster than it would be on the
performance workstation CPU.
Access to Current Data:
Remote file access enables the system manager to view/analyze `RAW'
logfile data. Global and Application data can be viewed to the last
five minute sample logged, and Process data can be viewed to the last
one minute sample logged.
Disc Space Requirements:
Remote file access does not required any additional disk space on the
performance workstation. Local file access requires that an
`EXTRACTED' logfile is downloaded to the hard disk of the performance
workstation (unless a Lan Manager shared directory is available on the
host HP9000).
Local File Access:
Local File Access implies the following: the system manager has run
the extract program on the HP 9000 host and generated an `EXTRACTED'
logfile. Using a binary transfer program of the system managers
choice (not supplied with HP LaserRX/UX) the extracted logfile has
been downloaded to the local disc on the performance workstation for
analysis. Lan Manager shared directories are also supported for local
file access. Note that only `EXTRACTED' logfiles can be analyzed
locally. Finally the system manager has locally opened the downloaded
`EXTRACTED' logfile for analysis.
Methods of Connection
The remote data communications solution provided with HP LaserRX/UX is
based on a propietary remote procedure call (RPC) functionality. Via the
performance workstation, the user establishes a remote connection with the
HP 9000 host machine where the performance data is being collected.
Transparent to the tool user, these RPC routines are initiated from the
performance workstation, executed on the HP 9000 host, and the resultant
data transferred back to the performance workstation. There are two modes
of data communication available:
- Local Area Network
The LAN solution is based on HP's NETIPC and requires two additional
software components outside of what is provided with HP LaserRX/UX. To
support LAN connections, the HP 9000 host machine must have the
LAN/9000 Series 300/800 Link software. On both the Series 300 and
Series 800 platforms the LAN/9000 Link software provides NETIPC as
well as the inetd daemon. The PC must have either Officeshare or
Network Services to use the remote LAN functionality.
This mode of connection between the performance workstation and HP
9000 host offers the following benefits:
- Speed (data transfer rate)
- Ease of connection to any one machine in the network.
- Serial
The serial solution is based on HP's EDCL protocol and requires no
additional software outside of what is provided with HP LaserRX/UX.
Remote SERIAL connections and data access is accomplished in the
following steps:
1) The performance workstation initiates a connection by specifying
a Basic Connection Command File which contains; login, password,
baud rate, parity, etc..
2) The Serial server (pcserver) on the HP 9000 host services the
connection request and establishes a remote logon.
3) From this point, the Serial server accepts RPC requests and sends
them to the LAN server (hcserver) for processing. Pcserver and
hcserver communicate directly via pipes (No LAN card/services are
required).
This mode of connection between the performance workstation and HP
9000 host offers the ability to connect over a wide ranges of
topologies utilizing Basic Serial Connection Files. You have the
flexibility to establish a connection and remotely access performance
data over the following supported configurations:
* Direct point-to-point connections
* Modem connections
* HP-certifies multiplexers
* HP-certified X.25 PADs
You can also establish connections and remotely access performance
data over the following unsupported configurations, but you are
responsible for providing technical support:
* Security mechanisms (dial-back units)
* Other multiplexers and data switches
* Other network topologies
